Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/acct/acct-minutes-90dec.txt

Text File | 1993-02-17 | 7.1 KB | 194 lines

CURRENT_MEETING_REPORT_


Reported by Cyndi Mills/BBN

ACCT Minutes

Agenda

Review and Revise:

Document


   o Internet Accounting Background Editor:  Don Hirsh,
     [e-mail]
   o Internet Accounting Architecture Editor:  Cyndi Mills,
     [e-mail]
   o Internet Accounting Meter Services Editor:  Mark Seger,
     [e-mail]
   o Internet Accounting Collection Protocols Editor:  Martin Dubetz,
     [e-mail]


Action Items:

Changes during review and revision:


  1. Distinguish between Internet (long-distance) and local-area
     accounting.  Internet accounting does not use attributes or
     user-ids (this reduces overhead).  Local area accounting may use
     attributes and user ids (these may be defined later).  The same
     accounting record formats are used for both Internet and local area
     accounting, although different profiles define which fields are
     mandatory, optional, and prohibited for each type.
  2. Refined ENTITY definition to be:

       oEnd-system network addresses.
       oIntermediate system network addresses.
       oAllow for different address types (IP address, NSAP address,
        etc.)
       oAll addresses are now absolute (no longer relative to meter
        loc).

     What about dynamically allocated network addresses (transients)?

                                1






   At least the service provider must be identified, if not the
   individual host.  Could service provider allocate IP address as
   unique subscriber identifier independent of transient address?
   Added a comment or unique id field which may be appended to the
   entity for use as an additional identifier.  Local area accounting
   only, please.  We need a mechanism to map transients tounique ids,
   but don't want to get involved in defining a directory service with
   real time propagation problems.  Maybe we should simply provide an
   appropriate field for use in the accounting record without
   specifiying how mapping is obtained.  This discussion should be
   continued on the mailing list.
3. VALUES -
   Counters don't reset to zero on reporting, so we are consistent
   with SNMP. Need to make sure this can work without too much
   additional memory from router.  Don't want to copy too often or
   maintain multiple ``snapshots'' of accounting tables in routers.
4. In background document, need to explain:

     oMulticasting is collected as an address.  No special
      consideration.  Dropped packets are tough luck - they may be
      counted and we can't distinguish retransmits at the IP level.
      Treat as performance problem, not accounting problem.  Network
      management should use other measures for dropped packets and
      guaranteed levels of service, etc.
     oExplain hierarchical collection better.  Each network generally
      accounts for its immediate subscribers, which may be
      end-systems (hosts) or other networks (routers or broadcast
      media with a network number).  Explain importance of
      recommending collection at internet entry and exit points
      (rather than at all routers) to minimize accounting overhead.
     oMake it even clearer that this group isn't recommending billing
      approaches.  How administrations bill (flat fee, cap, minimum,
      guaranteed delivery rates, penalties) is far beyond the scope
      of what we're trying to accomplish - we're just looking for a
      reliable way to report on network-layer network usage!
      (express goals/non-goals more emphatically)

5. Distributed rewrites/comments/updates of Architecture, Meter
   Services, and Collection documents.
6. Collecton protocol discussion.  Need help on deciding whether SNMP
   will be adequate - performance issues may be key.  Certainly SNMP
   authentication is an issue.  However, SNMP is the management
   protocol of choice, and is most widespread.
7. List of questions for Security Area, particularly regarding SNMP.
   Need help from Security Area.

     oPerformance of authenticated SNMP? Single-stream/multi-stream?
     oAuthentication:  do we need to add signatures for our meter
      ids?  Will SNMP ``just take care of this''?


                              2






       oAuthorization:  how do we tell our routers which management
        stations (plural) are authorized to collect information.
        (Access control).  I suppose someone will have to think about
        who can get the information from the collection point.  How do
        we resolve this in light of having one ``control'' station and
        multiple ``monitoring'' stations for each router.  How do we
        transfer title to ``control'' station when the original control
        station crashes, gets isolated, etc.  Does SNMP do access
        control?  ACLs (access control lists)?
       oConfidentiality:  We need encryption for sensitive traffic flow
        information.  Will SNMP do this for us, and key management too?
       oIntegrity:  Even if we don't need encrypted data, how about
        encrypted checksums?  What will SNMP do for us here?
       oDenial of Service.  What do we need to worry about here?
       oExport controls.  Do we need to define multiple variants of
        encryption?  Can we do this and still meet performance and
        other goals?
       oGoverment security requirements.  How to ensure that this will
        meet both commerical and government requirements?


Currrent Action Items:


  1. Enlist security help.
  2. Enumerate COLLECTION ISSUES (revisited) and post to list.
  3. Explain how SNMP might work and ramifications.
  4. Finish Updating Architecture document, distribute to list.
  5. Revise Meter definition document and distribute to Working Group
     list.
  6. Revise Background document and distribute to list.
  7. Write MIB (add to Meter Services).
  8. Estimate number of concurrent flows on backbone, e.g., NSFnet HTM.
  9. Submit outrageous statements to email list if it's quiet for too
     long to provoke resumption of appropriate discussion.


Overall Timetable:


   o Update current document set for storage in IETF-DRAFT ASAP.
   o Meet in January/February to expedite MIB definition.
   o Discuss collection issues on mailing list - after some discussion
     submit synopsis to ietf mailing list to solicit help from a wider
     audience.



                                3






Attendees

Robert Collet  /PN=ROBERT.D.COLLET/O=US.SPRINT/ADMD=TELEMAIL/C=US/@sprint.com
Robert Cooney           [e-mail]
Fred Engel
Mike Erlinger           [e-mail]
Brian Handspicker       [e-mail]
Don Hirsh               [e-mail]
Ken Jones               uunet!konkord!ksj
William Kutz            [e-mail]
Cyndi Mills             [e-mail]
Chris Myers             [e-mail]
Fred Ostapik            [e-mail]
Bill Rust               [e-mail]
Mark Seger              [e-mail]
Michael St.  Johns       [e-mail]
Jesse Walker            [e-mail]@decpa.dec.com
Kathy Wilde             [e-mail]
David Wood              [e-mail]
Lixia Zhang             [e-mail]



                                4